The present invention relates generally to the field of data communication and more specifically to rights management and securing data communicated in a network.
A growing interest in streaming distribution of multimedia content over Internet Protocol (IP) networks has resulted in a growing need for key management systems. One such streaming distribution system is the Aerocast Network™ developed by Aerocast, Inc. of San Diego, Calif. As discussed with reference to FIG. 1, although the existing phase 1 Aerocast Network facilitates delivery of content, it lacks security and key management for the network.
FIG. 1 is a block diagram of a network 100 (by Aerocast) for facilitating streaming of content over a communication network.
Among other components, network 100 includes a content provider 102 for generating content intended for a consumer 116, Internet 114 through which content is streamed, and a central server 104 to which content provider 102 publishes its contents. Central server 104 contains a database 108 for storing content information, and a search engine 110 for searching database 108. Network 100 further comprises a provisioning center 106, and caching servers 112, 113 and 115.
In operation, consumer 116 wishing to access content by content provider 102, streams the content from the closest caching server, in this case, caching server 115. In conventional systems without caching servers, consumer 116 desiring such content streams obtains content directly from content provider 102. Not only does this result in poor content quality, delays associated with inadequate bandwidth may result. By using the caching servers, network 100 avoids disadvantages associated with direct streaming of digital content from content provider 202. Caching servers 112, 113 and 115 may be local DSL (digital subscriber line) providers, for example.
Network 100 provides a further advantage. When searching for content, consumer 116 need not search any and all databases on Internet 114. All content providers (including content provider 102) on network 100 publish descriptions of their content to a single central database 108. For video content for example, such descriptions may include the movie name, actors, etc. In this manner, when content is desired, consumer 116 uses search engine 110 to search database 108. When the content is found, database 108 thereafter provides a link to content provider 202 having the desired content. Content provider 102 is then accessed by consumer 116 to access the desired content in more detail. Such details include pricing information, etc.
A mechanism is provided whereby consumer 116 provides a list of caching servers closest to it to content provider 102. In response to consumer 116's request, content provider 102 selects the appropriate caching server closest to consumer 116 for streaming the content. It should be observed, however, that in today's Aerocast network content is streamed in the clear by network 100. Disadvantageously, because it is unprotected, the content may be intercepted by an unauthorized consumer resulting in substantial losses to content providers and consumers.
Some of the disadvantages of network 100 are resolved by the above mentioned related U.S. Patents, commonly owned and hereby incorporated by reference as if set forth in its entirety in the present specification.
Generally, to deliver, manage and control streaming content, several different protocols may be employed. For example, a collection of protocols namely RTP (real time protocol), RTCP (real time control protocol) and RTSP (real time streaming protocol) may be employed for streaming real-time data. RTP specified in RFC (request for comments) 1889 runs on top of UDP (user datagram protocol). Among other functionalities, RTP provides end to end transport functions for real time transmission of content such as audio and video over point to point or multicast services. RTCP (Real Time Control Protocol) is a companion protocol providing QoS (quality of service) monitoring and delivering statistics on the media stream session, which may be used by the sender to adjust its timing. In addition, at least in a point-to-point case (and possibly in the multicast case) RTP and RTCP are accompanied by RTSP (Real Time Session Protocol), used to request particular content, provide content description, pause and re-start the media stream for point-to-point connections, etc.
Conventionally, a user wishing to stream content using the collection of protocols begins by generating RTSP messages, each RTSP message having a header and a payload. The RTSP header for each payload contains content identification (RTSP URL) for the content that is being requested or played out. Disadvantageously, the user's viewing patterns can be observed in this manner. One technique for preventing this outcome is by encrypting the entire RTSP message including the header.
Conventionally, this would require a security implementation at a lower layer, such as IPSec (Internet Protocol Security). While IPSec is capable encrypting a whole IP packet, it does require support from the operating system. Even if the disadvantage of requiring an operating system is overcome, IPSec is relatively complex and difficult to administer. Another option is to employ SSL (Secure Sockets Layer)or TLS (Transport Layers Security) for encrypting the entire RTSP message. However, both SSL and TLS are inoperable over a UDP (User Datagram Protocol)-based transport. Therefore, SSL and TLS cannot be used to secure RTCP. In any event, disadvantageously, IPSec, SSL and TLS all come with key management systems that lack efficiency and scalability.
Therefore, there is a need to resolve the aforementioned problems and the present invention meets this need.